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Human  Systems  Integration  (HSI)  utilizes  a  variety  of  analysis  methods  to  evaluate  systems  with  respect  to 
seven  key  domains:  manpower,  personnel,  training,  human  factors  engineering,  personnel  survivability, 
habitability  and  safety  &  occupational  health.  A  critical  part  of  the  "I"  in  HSI  is  the  tradeoff  analysis  where 
system  features  and  attributes  are  "traded-off"  to  satisfy  constraints  on  system  life  cycle  cost,  performance, 
and  development/delivery  schedule.  Members  of  this  panel  will  discuss  general  HSI  tradeoff  lessons 
learned  based  on  their  experiences  in  support  of  Naval  surface  acquisition  programs,  focusing  on  the 
mechanics  of  initiating  and  completing  HSI  tradeoff  analyses.  These  experiences  include  interactions  with 
people  and  hardware/software  (e.g.,  data  collection,  formatting,  processing,  etc.),  timelines/deadlines  to 
complete  analyses  and  make  decisions,  and  any  required  support  activities  (e.g.,  meetings,  briefings,  etc.). 
Each  panelist  will  share  experiences  from  the  perspective  of  one  of  three  key  acquisition  positions  for  HSI: 
Technical  Professional,  Program  Manager,  or  Support  Contractor. 


INTRODUCTION 

The  Department  of  Defense  Acquisition  System  is  a 
multilayered  process  that  attempts  to  simultaneously 
coordinate  activities  between  program  management,  systems 
engineering,  contracting,  and  logistics.  As  outlined  in  the 
Department  of  Defense  Instruction  5000.02  (2008),  a  Human 
Systems  Integration  (HSI)  plan  must  be  included  in  the 
acquisition  strategy  and  systems  engineering  plan  for  any 
system  to  address  the  following  seven  HSI  domains: 
manpower,  personnel,  training,  human  factors  engineering, 
habitability,  survivability  (of  personnel),  and  safety  & 
occupational  health. 

The  ultimate  goal  of  HSI  analyses  is  to  ensure  that  as 
many  requirements  relative  to  the  seven  domains  for  a  system 
(or  system  of  systems)  are  satisfied  within  the  constraints  of 
life  cycle  cost,  performance,  and  development/delivery 
schedule.  However,  depending  on  the  requirements  and 
constraints,  the  analysis  needs  within  a  particular  HSI  domain 
or  between  domains  can  be  complex  and  challenging. 

Chapanis  (1996)  describes  a  general  example  of  tradeoffs 
in  systems  engineering  as  follows:  “...suppose  Function  A  can 
be  performed  faster  on  Computer  System  X,  but  Function  B 
can  be  performed  faster  on  Computer  System  Y...How  do  you 
strike  a  balance  between  the  savings  in  time  versus  the  cost  of 
errors?  Does  increased  operator  comfort  increase  productivity 
and,  if  it  does,  how  can  that  be  translated  into  dollar  savings? 
Since  more  highly  selected  personnel  require  less  training,  is  it 
better  to  spend  more  money  on  selection  or  on  training?”  (p. 
283). 

Consider  asking  such  questions  relative  to  multiple 
systems  on  a  new  construction  or  modification  of  a  U.S.  Navy 
ship.  As  a  true  system  of  systems,  a  typical  ship  has 


machinery  spaces,  combat  systems  spaces,  a  flight  deck,  and 
living  quarters.  Because  of  this  complexity,  a  variety  of  HSI 
tradeoff  needs  may  arise,  and  are  typically  context  specific. 

But  how  does  one  conduct  a  cross  domain  tradeoff 
analysis?  What  are  the  elements  of  the  analysis  process? 
During  this  panel  discussion,  participants  will  provide  lessons 
learned  that  address  the  following  key  questions: 

•  How  does  the  acquisition  phase  or  maturity  of  design 
affect  the  nature  and  impact  of  conducting  tradeoff 
analyses? 

•  What  factors  precipitate  a  need  for  a  tradeoff  analysis? 

•  What  factors  influence  the  technical  scope  of  a  tradeoff 
analysis?  How  can  this  scope  vary  for  different  types  of 
domain  tradeoffs? 

•  What  kinds  of  people  interactions  are  needed  to  conduct  a 
tradeoff  analysis? 

•  What  analyses  require  close  collaboration  with  other 
engineering  elements,  and  how  best  do  you  obtain  that 
collaboration? 

•  What  techniques  or  tools  are  useful  when  conducting  a 
tradeoff  analysis? 

•  What  are  typical  implications  of  tradeoff  analyses  on 
engineering  decisions/activities?  What  about  implications 
on  program  management  decisions/activities? 

•  What  kinds  of  engineering  and  program  management 
risks  relate  to  tradeoffs? 

•  Which  tradeoffs  are  most  challenging? 

NITA  LEWIS  SHATTUCK 

In  the  area  of  Defense  acquisition,  tradeoffs  are  constantly 
being  made,  either  implicitly  or  explicitly.  A  senior  decision 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 
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maker,  recognizing  the  high  cost  of  manpower,  sets  the 
manning  requirement  for  a  new  ship  platform  at  a  nominal 
number.  Whether  or  not  it  is  acknowledged,  he  has  made  a 
tradeoff.  In  the  decision  maker’s  mind,  the  trade  is  between 
cost  and  manpower  -  but  the  tradeoff  has  far-reaching 
ramifications  that  will  almost  certainly  affect  other  HSI 
domains  of  personnel,  training,  human  factors  engineering, 
habitability,  survivability  (of  personnel),  and  safety  & 
occupational  health. 

Consider  the  case  in  which  the  manning  requirement  is  set 
at  an  arbitrarily  low  number  for  a  ship  class.  This  decision 
affects  the  performance  of  the  entire  system  in  both  direct  and 
indirect  ways.  The  work  on  the  ship,  including  standing  watch 
and  maintenance,  is  fixed  -  although  it  varies  with  ship 
activities  and  evolutions.  With  fewer  sailors  onboard,  there  are 
fewer  bodies  available  to  do  this  fixed  amount  of  work. 
Consequently,  the  sailors  must  work  longer  hours  to 
accomplish  the  work,  resulting  in  cumulative  fatigue  and  an 
ever-increasing  sleep  debt. 

While  this  may  seem  to  be  a  small  problem,  the 
downstream  effect  of  the  manning  decision  may  be  that  sailors 
choose  not  to  work  on  this  platform,  making  retention  and 
promotion  a  challenge.  In  order  to  keep  sailors  on  the  ship, 
pay  bonuses  must  be  offered — offsetting  the  original  cost¬ 
saving  effort.  The  sailors  on  the  under-manned  ship  may  be  so 
tired  and  sleep-deprived  that  they  make  mistakes  or  fail  to 
perform  the  required  maintenance,  resulting  in  costly  mishaps 
and  safety  issues.  In  emergency  conditions,  such  as  that 
experienced  by  the  USS  Cole ,  there  may  not  be  enough  able- 
bodied  sailors  to  perform  critical  tasks  such  as  firefighting, 
resulting  in  a  threat  to  system  and  personnel  survivability. 

Because  manning  levels  for  the  ship  have  been 
minimized,  the  ship  has  fewer  qualified  watchstanders  - 
making  it  ever  harder  for  junior  sailors  and  officers  to  get  the 
training  and  experience  required  for  qualification  and 
promotion.  The  need  to  perform  multiple  jobs  (i.e.,  the  ‘hybrid 
sailor’)  creates  more  pressure  on  training  and  performance; 
over-tasking  of  the  individual  sailor  is  common.  The  resulting 
decline  in  morale  will  certainly  impact  the  level  of  motivation 
and  individual  sailor  performance  and  will  ripple  through 
overall  system  performance.  Ships  will  fail  inspections  and 
readiness  levels  will  be  compromised,  all  resulting  from  a 
simple  tradeoff  decision  to  cut  back  on  the  number  of  sailors. 

HSI  offers  the  opportunity  for  an  early  exploration  of 
decisions  such  as  those  described  in  the  previous  example. 
Making  the  implications  of  tradeoff  decisions  available  for 
decision  makers  to  consider  will  result  in  better-informed  and 
more  innovative  material  and  non-material  solutions  for 
acquisition  challenges. 
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pursues  her  research  interests  in  human  fatigue  in  operational 
settings,  individual  and  team  performance.  She  has  her  Ph.D. 
in  Behavioral  Science  from  the  University  of  Texas  School  of 
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JOHN  WINTERS 

The  top-level  objectives  of  HSI  are  optimizing  total 
system  performance  and  minimizing  total  ownership  cost. 
The  terms  minimize  and  optimize  do  not  translate  well  into 
requirements  documents,  so  the  working-level  HSI  or  domain 
practitioner  must  establish  lower-level  objectives  to  address. 
Success  in  making  a  domain  tradeoff  requires  scoping  the 
tradeoff  to  these  and  other  constraints. 

First,  the  tradeoff  needs  to  fit  the  program’s 
organizational,  contractual,  and  political  framework.  The  HSI 
focus  on  total  ownership  cost  and  total  system  performance  is 
common  to  systems  engineering,  which  illustrates  the  need  for 
tight  integration  of  HSI  with  systems  engineering  aspects  of 
the  program.  The  components  of  the  tradeoff  -  in  particular 
the  costs  incurred  and  savings  realized  -  need  to  be  within  the 
authority  of  the  part  of  the  organization  making  the  tradeoff. 
The  tradeoffs  that  are  most  likely  to  succeed  are  those  whose 
costs  and  benefits  are  fully  within  the  established  systems 
engineering  scope  or  the  authority  of  the  Program  Manager, 
and  all  relevant  domains  must  be  in  concurrence. 

The  hierarchy  of  the  Department  of  the  Navy  illustrates 
the  difficulty  in  making  tradeoffs  between  acquisition  cost  and 
manpower,  as  the  responsibilities  for  acquisition  and 
manpower  in  the  Navy  reside  with  separate  Assistant 
Secretaries  of  the  Navy.  Contractual  limitations  to  be 
considered  include  (1)  the  Statement  of  Work  or  Work 
Breakdown  Structure  of  the  project,  and  (2)  the  contractual 
deliverables.  Any  significant  work  or  product  that  needs  to  be 
traded  off  -  as  an  addition  or  a  subtraction  -  needs  to  be 
aligned  with  these  constraints. 

Second,  the  tradeoff  must  be  scoped  to  the  right 
timeframe.  Typically,  any  cost  incurred  for  a  tradeoff  must  be 
recoverable  within  the  near-term  funding  cycle  for  a  Program 
Manager,  which  would  typically  be  two  or  three  years.  Also, 
program  schedule  may  not  be  a  variable  that  can  be  traded  off, 
particularly  for  ship  systems.  For  most  ship  systems,  their 
completion  or  delivery  dates  are  tied  to  construction  or 
overhaul  periods  for  ships,  which  are  not  under  the  control  of 
the  Program  Manager  and  are  unlikely  to  be  altered.  The 
financial  costs  and  benefits  of  HSI  may  also  be  associated 
with  different  timeframes.  Valerdi  and  Liu  (2010)  present 
three  levels  of  HSI  cost,  beginning  with  the  cost  to  carry  out 
HSI  as  part  of  systems  engineering,  which  would  include  the 
cost  of  defining  requirements  or  conducting  a  tradeoff 
analysis.  The  second  level  is  the  cost  of  satisfying  those 
requirements  in  the  design,  and  the  third  level  is  the  long-term 
total  ownership  cost  or  savings  of  the  earlier  HSI  investment 
(or  lack  thereof).  Costs  within  individual  domains  can  be 
difficult  to  predict,  and  differing  timeframes  only  makes  these 
costs  more  difficult  to  trade  off  against  one  another. 

Third,  the  tradeoff  must  specifically  address  a  program 
priority.  It  will  be  difficult  to  illustrate  how  a  tradeoff 
minimizes  total  ownership  cost  or  optimizes  total  system 


performance,  but  it  is  much  more  straightforward  to  tie  a 
tradeoff  to  performance  requirements,  to  manpower  and 
personnel  constraints,  or  documented  program  risks. 
Associating  a  tradeoff  with  a  program  risk  is  one  of  the  fastest 
ways  to  get  approval  because  it  addresses  something  of  direct 
importance  to  the  Program  Manager.  Domains  differ  in  their 
relevant  data  and  areas  of  interest,  meaning  that  trades  have  to 
be  made  in  different  “units  of  measure.”  Translating  the 
impact  in  each  domain  to  program  priorities  improves  the 
viability  of  the  tradeoff. 

Finally,  making  a  tradeoff  requires  relevant  supporting 
data.  Since  people  are  inherently  the  most  variable  part  of  the 
total  system,  different  decision  makers  will  have  different 
predictions  or  assumptions  about  how  they  will  impact 
performance.  The  proclivity  for  armchair  performance 
prediction  from  outside  the  HSI  community  can  be  best 
discouraged  by  collecting  the  relevant  data  or  completing  the 
relevant  analyses.  Performing  the  analysis  work  may  require  a 
specific  contractual  deliverable.  The  results  then  need  to  be 
condensed  or  translated  into  a  format  that  is  relevant  at  the 
level  of  the  individual  with  authority  for  the  tradeoff. 
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JAMES  A.  PHARMER 

Although  practitioners  in  the  HSI  domains  have  made 
great  strides  in  gaining  acceptance  into  the  system  acquisition 
process,  the  role  of  these  practitioners  is  not  often  readily 
apparent  to  the  practitioners  of  more  traditional  engineering 
and  program  management  disciplines.  In  other  words,  the 
traditional  acquisition  community  is  generally  aware  of  the 
requirements  to  “do  HSI”  but  still  often  at  a  loss  for  the  best 
way  to  integrate  this  new  discipline  (or  set  of  disciplines)  into 
the  process.  Therefore,  it  is  incumbent  on  the  HSI 
practitioners  to  provide  some  education  to  these  practitioners 
on  the  value  provided  by  including  HSI  considerations  into  the 
conventional  cost,  schedule,  and  performance  tradeoff  process. 

Unfortunately,  two  issues  arise  when  trying  to  provide 
this  “education.”  First,  hard  and  fast  requirements  for  HSI  are 
still  in  the  beginning  stages  of  development.  Despite  support 
for  HSI  at  high  levels  within  the  Department  of  Defense  and 
other  governmental  organizations,  the  requirements  for  a 
Program  Manager  are  still  somewhat  ambiguous.  Program 
Managers  know  that  they  are  required  to  fund  professionals  in 
the  domains,  but  many  do  not  know  how  to  utilize  them. 
Therefore,  an  assertion  that  HSI  has  value  to  the  program 
meeting  a  higher  level  requirement  is  difficult  to  defend  if  the 
program  is  technically  meeting  the  requirement  simply  by 
funding  HSI  practitioners. 

Second,  because  HSI  is  still  in  its  infancy,  there  are  few, 
if  any,  major  acquisition  programs  that  have  fully 


implemented  HSI  considerations  into  the  acquisition 
tradespace  and  progressed  into  operations  and  sustainment  of 
the  designed  systems.  The  paucity  of  data  from  programs  that 
have  “walked  the  talk”  limits  the  ability  to  study  its  impact 
across  the  lifecycle.  For  this  reason,  an  assertion  that  HSI  has 
value  cannot  easily  be  communicated  in  terms  of  returns  on 
investment  from  cost,  schedule,  or  performance  standpoints, 
precisely  the  language  that  is  important  to  a  Program 
Manager. 

Since  HSI  requirements  are  not  often  clear  and  there  is 
scarce  data  on  its  return  on  investment,  HSI  practitioners  need 
to  educate  traditional  acquisition  professionals  through 
actively  participating  during  the  systems  engineering  process. 
This  means  educating  themselves  on  the  factors  the 
disciplines,  both  internal  and  external  to  HSI,  are  considering. 
For  example,  for  many  Navy  assets  (ships,  aircraft,  etc),  a  key 
consideration  is  overall  weight,  which  adds  to  fuel  costs,  and 
structural  engineering,  and  material  costs.  Therefore,  a  human 
factors,  habitability,  training,  or  manpower  “solution”  that 
adds  weight  (cost)  can  be  a  difficult  challenge  unless  it  can  be 
justified  by  a  large  performance  payoff. 

Knowing  the  performance  requirements,  and  whether  or 
not  the  program  is  on  a  path  to  meet  them,  can  provide 
leverage  to  the  argument  for  the  HSI  solution.  Since  cost  is 
often  the  most  important  consideration,  a  “solution”  couched 
in  terms  of  a  reasonable  prediction  of  increased  performance 
that  does  not  increase  acquisition  cost  or  schedule  is  perhaps 
the  most  powerful  argument.  The  point  is  that  if  the  HSI 
practitioner  understands  the  constraints  placed  on  the 
individual  on  the  other  side  of  the  tradeoff  discussion  (e.g.,  a 
weight  limitation),  an  HSI  solution  can  be  developed  that 
recognizes  that  constraint  as  a  limiting  factor.  Traditional 
systems  engineering  tradeoffs  between  such  disciplines  as 
hardware  and  software  engineering  are  performed  in  this  way. 
Participation  in  this  same  process  by  HSI  practitioners  makes 
the  job  a  little  more  challenging  but  it  is  the  essence  of  the 
systems  engineering  tradeoff  process. 
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DENNIS  WHITE 

There  are  actually  two  layers  of  HSI  Tradeoff  Analyses: 
1)  within  the  domains  of  HSI  and  2)  between  the  Human, 
Hardware  and  Software  systems.  The  Navy’s  HSI  community 
has  successfully  performed  tradeoff  analyses  across  the 
domains  (for  example,  trading  workflow  complexity  with 
personnel  selection),  and  has  been  integral  to  some 
system/subsystem  tradeoffs.  But  often,  the  success  of 


implementing  the  results  of  tradeoff  analyses  requires  the  use 
of  two  fundamental  skills  to  successfully  implement  tradeoffs: 
communication  and  compromise. 

Communication  involves  the  imparting  or  interchange  of 
thoughts,  opinions,  or  information  by  speech,  writing,  or  signs. 
The  real  impacts  to  system  design  occur  around  the  table 
where  all  players  are  participating  -  and  communicating.  As  is 
often  stated,  the  Program  Manager’s  concerns  revolve  around 
cost,  schedule  and  performance  (order  of  importance  may 
vary).  The  Human  Systems  Engineer  is,  at  the  end  of  the  day, 
a  Systems  Engineer,  because  HSI  is  an  integral  part  of  the 
systems  engineering  process  used  in  the  acquisitions 
(Secretary  of  the  Navy  Instruction  5000.2,  2008).  Therefore, 
the  Human  Systems  Engineer  must  be  able  to  translate  and 
communicate  the  value  of  human  performance  design  options 
that  support  operational  requirements  and  user  needs  into 
metrics  that  the  Program  Manager  and  other  members  of  the 
system  engineering  team  will  understand. 

Two  different  analyses  on  two  different  ship  designs  in 
the  recent  past  illustrate  the  success  -  and  failure  -  of 
successfully  engaging  the  program  leadership.  In  the  first 
example,  naval  architects  argued  against  a  two-story  high  Ship 
Command  Center  on  the  basis  of  structural  integrity  and 
constructability.  Although  human  performance  analysis  and 
other  design  experience  showed  the  value  in  increasing 
situational  awareness,  communication  and  execution,  this  had 
to  be  explained  in  terms  Mission  Performance,  which  included 
time  to  execute,  and  the  difficulty  to  achieve  the  same  level  of 
performance  in  a  single  story  design  option.  By  understanding 
the  naval  architect’s  problem  and  design  space,  the  HSI  team 
was  able  to  successfully  present  (and  win)  the  argument  for  a 
two  story  command  center. 

The  second  example  involved  a  study  looking  at  reducing 
workload  through  machinery  space  design  with  the  goal  of 
reducing  manning.  The  difficulty  in  translating  workload  to 
manpower  to  sailor  billets  to  dollars  rendered  an  answer  that 
leadership  just  couldn’t  grasp  on  a  single  PowerPoint  slide. 
The  analysis  was  good,  the  communication  was  not,  and  no 
impact  was  made  to  the  program. 

Compromise  (a  settlement  of  differences  by  mutual 
concessions)  is  another  skill  necessary  to  impact  design.  The 
key  objectives  are  Total  System  Performance  and  Total 
Ownership  Cost  across  the  hardware,  software,  and  people, 
including  user  preferences.  US  Navy  Ship  and  Ship  systems 
(propulsion,  ship  control,  weapon  systems)  have  key 
parameters,  including  weight,  balance,  displacement  and 
power.  Recognizing  that  some  things  are  indeed  negotiable, 
and  knowing  which  parameters  absolutely  cannot  be 
compromised,  allows  the  Human  System  Engineer  to 
collaboratively  engage  the  rest  of  the  design  team  to  meet 
these  objectives.  This  may  include  ‘compromise’  on  the 
analysis  itself:  no  program  has  enough  money  to  do  everything 
desired,  and  the  successful  engineer  will  craft  an  effective 
analysis  that  answers  the  questions  and  meets  cost  and 
temporal  constraints. 

For  example,  in  a  recent  ship  design,  one  organization 
proposed  a  high  fidelity  simulation  of  a  command  center  to 
determine  the  layout  of  people  and  equipment.  The  program 
had  neither  the  consoles  (final  design  has  just  been  settled,  but 


nothing  manufactured)  nor  the  software  (ship  construction 
requires  a  very  early  lead  time,  often  before  software  systems 
are  complete  or  designed).  Another  organization  proposed  a 
lower  fidelity  option  to  focus  on  the  problem  at  hand: 
optimizing  the  layout  of  people  and  equipment  based  on 
requirements  and  anticipated  functionality.  The  low  fidelity 
option  was  funded,  and  made  significant  contributions  to  the 
final  approved  layout  of  the  command  center.  Would  the  high 
fidelity  option  have  provided  better  analysis?  Absolutely,  but 
it  would  have  been  two  years  after  the  ship  was  already  under 
construction. 
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